Why is this change necessary?

The template had no Release workflow. The existing Publish / Publish to Staging workflows re-run lint/test/build themselves, duplicating everything CI already does for the commit. We want a release path that instead relies on a passing CI run — modeled on the copier-nuxt-python-intranet-app release.yaml — while publishing to PyPI (using the existing publish.yaml as the PyPI reference).

While wiring this up we also found that instantiated repos hit pylint R0801 duplicate-code between git_tag.py and extract_project_version.py, because this repo carried a pre-refactor fork of git_tag.py (symlinked from copier_template_resources/) that parsed pyproject.toml itself.

How does this change address the issue?

• CI builds the distribution. Added a build job to ci.yaml.jinja that runs uv build --no-sources and uploads a python-package-distributions artifact (if-no-files-found: error), wired into workflow-summary (needs + fail-check).
• New release.yaml.jinja. Manual workflow_dispatch with a dry_run input, generated for both libraries and executables. A guard job requires the ci.yaml run for the current commit to be completed/success (including the workflow-summary job), extracts the version via extract_project_version.py, and confirms the tag is absent — real releases must run from main. The flow then branches on deploy_as_executable:
  • Library: download the CI-built dist (never rebuilds), publish to Test PyPI and verify a fresh install, push the v<version> tag, publish to PyPI and verify again, then create a GitHub Release with generated notes.
  • Executable: push the v<version> tag, download every exe-{os}-{python} artifact the CI executable job built, package each (tar on Linux / zip on Windows), and attach them all to a GitHub Release. No PyPI publish.
    All tag/publish/release jobs are skipped on dry_run.
• Aligned git_tag.py with base/nuxt. Replaced the local fork with the base version (--version required, no pyproject.toml parsing), and collapsed the copier_template_resources/ symlink into a real file at template/.github/workflows/git_tag.py (matching its sibling extract_project_version.py). Updated all call sites in publish.yaml and release.yaml to source the version from extract_project_version.py and pass --version.
• Docs. Documented the Release workflow in the generated README, plus a TODO to eventually merge Publish / Publish to Staging into Release.

What side effects does this change have?

• CI now has an extra build job on every run (gated {% if not is_frozen_executable %} to match publish.yaml).
• git_tag.py's CLI changed: --version is now required and it no longer prints/parses the version. Any external caller relying on the old no-arg print behavior must switch to extract_project_version.py.
• create-tag gained a needs dependency (guard in release.yaml, get-values in publish.yaml) to obtain the version.
• template/.github/workflows/git_tag.py changed from a symlink to a regular file; copier_template_resources/git_tag.py was deleted.

How is this change tested?

Rendered the template with copier (data1 / PyPI) and verified:

• ci.yaml, release.yaml, publish.yaml all parse as YAML; job graph, needs, and dry_run guards asserted correct.
• All git_tag.py call sites pass --version; version sourced from extract_project_version.py.
• pylint on the rendered scripts: 10.00/10 (previously exit 8 / R0801). ruff and pyright pass on the source git_tag.py.
• CodeArtifact conditional branches render structurally (kept for parity so existing CodeArtifact users aren't broken).

Final enforcement happens in the lint-matrix CI job, which generates across data1/2/3 and runs pre-commit on the output.

Other

• Fixed a pre-existing template bug: is_frozen_executable (used to gate entrypoint.py, main.py, publish.yaml, publish_to_staging.yaml) is undefined and evaluates falsy — so executable projects shipped with no entrypoint.py/main.py yet still got PyPI publish workflows. Renamed all guards (plus the CI build job) to the real deploy_as_executable question. release.yaml is intentionally ungated — it serves both cases and branches internally; publish.yaml / publish_to_staging.yaml stay library-only. Verified renders: executables now get entrypoint.py/main.py, no publish, and a release.yaml that attaches the CI-built executables; libraries get publish/release + the CI build job and no entrypoint/main.
• Test-data coverage gap (follow-up): after the fix, no tests/copier_data file is PyPI + library (data1/data3 = PyPI + executable, data2 = CodeArtifact + library), so lint-matrix no longer exercises the PyPI-library publish/release path. Consider a data file with python_package_registry: PyPI and deploy_as_executable: no.
• release.yaml's create-tag pushes the tag before publish-to-primary; the GitHub Release step then attaches to that existing tag (softprops/action-gh-release handles a pre-existing tag gracefully — no conflict).